1. Field of the Invention
This invention relates generally to methods and systems for providing and verifying a trusted source of certified time, and, more particularly, the invention relates to digitally time stamping electronic documents wherein the time stamp can be validated and verified as synchronized with an accepted standard.
2. Description of the Related Art
Electronic Commerce (e-commerce) is a rapidly expanding aspect of the economic world and demands the use of Electronic Commerce transactions. Such transactions, however, have outgrown the policies and controls that regulate traditional Paper Commerce. For example, a paper document can be typed, signed in ink, and mailed through the post office. The post office can then affix a time stamp and receipt at the destination. There are long standing legal and accounting policies that authenticate this type of transaction. When an electronic document is sent between two computers, however, it does not leave behind the same degree of tangible evidence. Even if the electronic document is stored in a computer""s memory, the contents, signature, and time stamp can be manipulated by anyone with access to the computer.
Accounting and legal regulatory bodies are currently developing and mandating Electronic Commerce certification processes to provide reliable authentication for electronic transactions much like those available for paper transactions. Many of the certification processes depend on the creation of a digital signature using public key cryptography that authenticates the xe2x80x9cWho,xe2x80x9d xe2x80x9cWhat,xe2x80x9d and xe2x80x9cWhenxe2x80x9d of a document.
Public key cryptography was developed in the 1970s to solve problems involved with symmetric key cryptography. In public key cryptography systems, two corresponding keys are generated. One key, called a private key, is held privately by the keyholder. A second key, called a public key, is published openly for anyone that wants to secretly communicate with the keyholder or verify the authenticity of messages sent by the keyholder. Because the sender and the receiver use different keys, public key cryptography is also known as asymmetric key cryptography.
To send a secret message with public key cryptography, an entity xe2x80x9cAxe2x80x9d encrypts a message using the public key of an entity xe2x80x9cB.xe2x80x9d xe2x80x9cAxe2x80x9d then transmits the encrypted message to xe2x80x9cB.xe2x80x9d xe2x80x9cBxe2x80x9d decrypts the encrypted message with xe2x80x9cBxe2x80x9d""s corresponding private key. Since the message encrypted with xe2x80x9cBxe2x80x9d""s public key can only be decrypted with the corresponding private key, held only by xe2x80x9cB,xe2x80x9d the privacy of the communication is ensured.
To authenticate the content and origin of a message, xe2x80x9cAxe2x80x9d uses a one-way hash function to create a message digest. A message digest is a fixed length data element that uniquely represents the source message. Since the hash function is one-way, nothing about the content of the source message can be inferred from the message digest. For example, two message digests from two messages that differ by only one character would appear to be a completely random reordering of characters. xe2x80x9cAxe2x80x9d then signs the message by encrypting the digest using xe2x80x9cAxe2x80x9d""s private key. The signature is typically appended to the message itself. xe2x80x9cAxe2x80x9d then transmits the signed message to xe2x80x9cB.xe2x80x9d In order to authenticate the received message, xe2x80x9cBxe2x80x9d uses the same one-way hash functions used by xe2x80x9cAxe2x80x9d to create a message digest from the received message. xe2x80x9cBxe2x80x9d then decrypts the encrypted digest using xe2x80x9cAxe2x80x9d""s public key. If the decrypted digest matches the digest created from the received message, then the received message must be the identical message from which the decrypted digest was originally derived. Furthermore, that the decrypted digest was decrypted using xe2x80x9cAxe2x80x9d""s public key ensures that the decrypted digest was originally encrypted with xe2x80x9cAxe2x80x9d""s private key. The successful matching of digests, therefore, ensures that the message received by xe2x80x9cBxe2x80x9d is the identical message signed by xe2x80x9cA.xe2x80x9d
Encrypting a message itself establishes secrecy. Signing a message provides for message authentication and establishes the xe2x80x9cwhoxe2x80x9d and xe2x80x9cwhatxe2x80x9d of a message. Encryption and signatures can also be combined by encrypting a message before creating a message digest and signature. By combining encryption and signatures, secret, authenticatable communications can be accomplished.
A very significant attribute of public key cryptography is that there is no need to share a secret key or to transmit a secret key from the keyholder to a proposed communication partner. It is, however, necessary to establish credibility for who owns public and private keys. For instance, xe2x80x9cCxe2x80x9d could claim to be xe2x80x9cAxe2x80x9d and send a message to xe2x80x9cB.xe2x80x9d To prevent being fooled, xe2x80x9cBxe2x80x9d needs to be sure that xe2x80x9cAxe2x80x9d""s public key, is in fact paired with the private key owned by a real xe2x80x9cA.xe2x80x9d A Certification Authority (CA) solves this problem. (Note: The use of the word xe2x80x9ccertificationxe2x80x9d in certification authority relates to the association of public keys with particular owners and is distinct from the concept of a Time Calibration Certificate (TCCert), as used herein, which relates to the certification of a clock as synchronized with an accepted standard.) CAs provide digital certificates which contain public keys and are used to transmit the public keys in a secure, authenticated manner to participants in e-commerce transactions.
In addition to the cryptographic techniques and digital certificates provided by CAs, security and authentication of transactions is also supported by an extensive body of protocol standards. It is necessary for xe2x80x9cAxe2x80x9d to format messages, signatures, message digests, etc., with protocols that can be recognized by xe2x80x9cB.xe2x80x9d Cryptography, digital certificates, protocols, and standards together make up what is termed the Public Key Infrastructure (PKI). With PKI, one can easily guarantee the xe2x80x9cwhoxe2x80x9d and xe2x80x9cwhatxe2x80x9d of a transaction.
xe2x80x9cWhenxe2x80x9d is a measure of the time at which an event occurred and is a concept easily taken for granted. A worldwide system of time standardization is in operation. Each country that is signatory to the Treaty of the Meter maintains a National Timing Laboratory (NTL), which houses the local country""s standard time clock. These clocks are kept synchronized to the world standard of time maintained in Paris, France. The world standard for commercial time is Coordinated Universal Time (UTC). In the United States, Congress has mandated that official United States xe2x80x9ctimexe2x80x9d follow the clock maintained by the National Institute of Standards and Technology (NIST), located in Boulder, Colorado. This standard is referred to as UTC-NIST. Any time stamp for a transaction that must survive technical, auditing, or legal scrutiny must be made by a clock that is synchronized to UTC-NIST, and the synchronization process must be xe2x80x9ctraceable.xe2x80x9d Throughout this document, reference is made to UTC-NIST but the invention described is applicable to operation in any country and with standard time clocks maintained by any country""s respective national timing laboratory.
The use of xe2x80x9ctraceablexe2x80x9d clocks in paper commerce has been sufficient to provide the xe2x80x9cwhenxe2x80x9d of ordinary paper transactions. While there have been numerous cases of falsification of dates on paper documents, the risk to commerce has been relatively small. In the case of e-commerce, however, falsification of dates creates a much greater risk because it is possible to invade computer-directed processes and effect fraud on a very large scale. Such computer crimes frequently involve falsification of electronic time stamps; and for this very reason, protection of the electronic clocks that generate those time stamps from tampering is a high priority in Electronic Commerce.
Current network procedures provide for the synchronization of all workstation clocks in a network. NIST and other agencies provide network time servers that have clocks traceable to UTC-NIST. Client workstations can synchronize their time with the network time servers through a common protocol. The Network Time Protocol (NTP) is commonly used in TCP/IP networks such as the Internet, but other protocols are also used.
Unfortunately, once a local workstation clock is synchronized to the network time server, its time may be subject to manipulation regardless of the reliability of the source network time server. Thus far, little work has been done to ensure that the source of the time used to generate time stamps can be trusted. Today, the majority of applications utilizing time stamps simply use the system clock from their host system. Procedures for setting or offsetting a system clock are commonly known. Thus, there is no inherent trust in a system clock in a conventional system.
Attempts to overcome this problem include time stamp sequencing wherein the time stamp incorporates information regarding the order in which documents are time stamped in relation to other time-stamped documents. (See, for example, U.S. Pat. No. 5,136,647 to Haber et al.) Other attempts to overcome the problem incorporate the use of other time sources such as NTP or Global Positioning System (GPS). While these attempts are significant improvements over using the system clock, the improvements still fall short of fitting into the trust models required for electronic business today.
Still other systems employ the use of certified time that is maintained by a trusted third party""s system located outside the local network. The trusted third party system remains synchronized with UTC-NIST through a common protocol. The local network application server then establishes communication with the third party""s system whereby a data object (document or message digest) is sent to the third party system where a xe2x80x9ctime stampxe2x80x9d is affixed to the data object, either in clear text or in cryptographically embedded text. Such a system may be impractical, however, considering the need for external communication for each instance of time stamping, especially when many time stamps are required by the local network.
Another system introduces a local clock into the local network, thus avoiding the problems associated with obtaining time stamps from an outside source. The local clock must be periodically synchronized with a UTC-NIST traceable clock. In order to avoid frequent certification and calibration between the local clock and the UTC-NIST traceable clock, the local clock is advantageously a cesium atomic clock. Cesium atomic clocks are commercially available and their frequency, and hence time, is derived from an atomic phenomena caused by the energy difference of certain cesium atom electron orbits. Thus, as long as the cesium atomic clock is operating, it will be accurate enough to satisfy most practical applications. Such clocks only lose one second in 30,000 years of normal operation. For this reason, cesium atomic clocks are termed xe2x80x9cprimary reference sources.xe2x80x9d Unfortunately, when used locally, there is still the possibility that the time value in the clock could, through system malfunction or intentional manipulation, be altered to an incorrect value that would not be apparent to a user.
Trusted time, in the context of the present invention, is time that is certified to be traceable to the legal time source for the application in which it is being used. The legal time source for commercial applications operating in the United States, as legislatively mandated by Congress, is the National Institute of Standards and Technology (NIST). The infrastructure for providing trusted time must provide a strong trust model, including a certification log for auditing and to prevent repudiation at a later date.
The need for trusted time has become recognized over the last two years as marked by the launch of standardization activities in the The Internet Engineering Task Force (IETF). In addition, most Certification Authority (CA) product and service vendors have announced development activities and new products in this area. The present disclosure describes a Trusted Time Infrastructure (TTI) that meets the requirements for providing trusted time. The present disclosure also shows how the TTI fits in with the trust models and cryptographic standards that have been developed to ensure that secure and legally binding electronic transactions can take place today.
A Trusted Time Infrastructure (TTI) system provides time stamps, in the form of trusted temporal tokens, for electronic documents from a local source. A preferred embodiment of the system comprises a trusted master clock, a trusted local clock, and a network operations center. The trusted master clock and the network operations center are located within secure environments controlled by a trusted third party. The trusted local clock may be located in an insecure environment. The trusted master clock is certified to be synchronized with an accepted time standard, such as a national time server. The trusted local clock, which issues time stamps, is certified to be synchronized with the trusted master clock. Time stamps and certifications are signed by the issuing device using public key cryptography to enable subsequent authentication. The network operations center logs clock certifications and responds to requests for authentication of time stamps.
The delivery of trusted time by the trusted local clock is ensured by: (1) the physical security of the devices in the system; (2) authentication of communications between the devices in the system; (3) the link of certifications through which time can be traced to an accepted standard; and (4) the specified accuracy of clocks within the system.
In an alternative embodiment, each issued time calibration certificate incorporates the time calibration certificate of the issuing clock. The time calibration certificate of the trusted local clock is then incorporated into the issued trusted temporal tokens. Accordingly, the chain of certifications from which trusted time is derived from an accepted source is incorporated into each trusted temporal token.
In another embodiment, the system provides a local source of trusted time through a trusted local clock. In still another embodiment, methods of billing clients are based upon the number of trusted temporal tokens issued or, alternatively, based upon the number of clock certifications performed. Billing features of the system support the billing methods. These and other aspects of the present invention will be further described in the detailed description that follows.